Section: Application Domains

Modular design of embedded systems with interface theories

In 2006, with the oportunity of the SPEEDS European project on embedded system design, we decided to open a new research track on contract-/interface-based design. Our objective was to provide theory, methods and tools to support the design of embedded software in transport system industries. According to our understanding of industrial needs, gained during the SPEEDS European project, the following requirements apply to the notions of contract and interface and have been used to guide our research on this topic:

• Complex embedded and reactive systems are generally developed under a multi-layered OEM-supplier chain. Hence, a contract-based methodology should offer provision for formalizing the technical part of contractual relations. This should be achieved by formalizing, for a considered subsystem: 1/ its context of use (assumptions), and 2/ what is expected from the subsystem (guarantees). Assumptions and guarantees can be specified separately, or in a single automata-theoretic structure called interface.

• When developed under a contract-/interface-based methodology, subsystems or components should be designable in isolation, by including the needed information regarding possible future contexts of use. Subsystems or components should be substitutable to their specifications, meaning that their integration should raise no problem.

• Large systems are concurrently developed for their different aspects or viewpoints by different teams using different frameworks and tools. Examples of such aspects include the functional, reliability, timing, memory and power aspects. Each of these aspects requires specific frameworks and tools for their analysis and design. Yet, they are not totally independent but rather interact. The issue of dealing with multiple aspects or multiple viewpoints is thus essential. This implies that several contracts or interfaces are associated with a same system, sub-system, or component, namely at least one per viewpoint. These contracts/interfaces are to be interpreted in a conjunctive way and modular reasoning methods have to be developed to support large sets of contracts.

• The need for supporting conjunctive contracts/interfaces also follows from the current practice in which early requirement capture results in many elementary requirements. These requirements typically consist of English text, semi-formal languages whose sentences are translatable into predefined behavioral patterns, or even graphical scenario languages.

• It is highly desirable that designing by contracts and interfaces has the mildest possible impact on the design process, a key proprietory asset to all major companies.